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This  paper  overviews  previous  years  research  and  specifics  in  detail  three  computer  systems  functionally  similar  to 
subsets  of  existing  U.S.  Navy  ship  and  submarine  systems.  The  computer  system  descriptions  represent  no  specific 
system  either  deployed,  under  development,  or  proposed. 


For  each  system,  the  computer  system  performance  requirements  and  computer  equipment  selection  criterion  arc  given. 
The  intent  is  to  provide  meaningful  lest  problems  for  university  based  computer  science  research  of  real  time  distributed 
systems.  The  distributed  processing  scenarios  assume  that  the  research  testbed  systems  contain  at  least  three 
processors. 
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1.0  Introduction 


IBM's  efforts  in  support  of  the  Office  of  Naval  Research's  Real  lime  System  Initiative  have  been  accomplished  in  two 
phases.1  In  phase  1  of  the  project  IBM  integrated  its  Real- lime  Communication  Network  (RICN)  prototype  LAN 
with  Carnegie  Mellon  University's  (CMU's)  Advanced  Real  lime  System  (A  R‘IS)  operating  system  (OS)  at  the  host 
OS  kernel  to  network  interface  unit  OS  kernel  level.  IBM  also  performed  experiments  using  RICN  to  quantify  the 
benefits  of  having  network  support  for  global  semaphores  rather  than  using  a  centrally  located  process.  A  factor  of  5 
difference  in  performance  was  measured,  finally,  IBM  developed  and  performed  initial  test  on  software  designed  to 
predict  network  scheduling  performance  and  to  measure  actual  results.  Hie  schcdulability  prediction  software  has  been 
provided  to  CMU  and  incorporated  into  the  distributed  version  of  CMU's  Scheduler  l -2-3.  a  system  response  time 
engineering  tool. 

In  phase  2  of  this  research  effort  the  ARTS/RTCN  interface  was  extended  to  the  application  level  through  a  cooper¬ 
ative  effort  between  IBM  and  CMU.  The  design  of  the  ARTS  OS  Version  1.0  allows  selection  of  any  one  of  several 
communication  protocol  stacks  including  RTCN  and  Cthcrnct.  Ibis  facilitates  performance  evaluation  of  these  pro¬ 
tocol  stacks  for  the  hard  real-time  application  environment. 

The  importance  of  the  RTCN  research  prototype  is  that  RTCN  and  its  predecessor  (currently  in  use  on  AN.BSY-I) 
are  the  only  LANs  that  have  been  explicitly  designed  from  inception  to  support  rate  monotonic  scheduling  of  commu¬ 
nications  both  at  the  message  and  packet  level  throughout  the  protocol  slack,  not  just  at  the  media  access  level.  In 
short,  RTCN  is  the  only  fiber  optic  LAN  that  is  available  for  prototyping  and  measuring  the  quantitative  benefits 
associated  -with  using  rate  monotonic  scheduling  across  the  entirely  of  a  real-time  distributed  system. 

IBM  has  provided  an  RTCN  LAN  to  the  Software  Fnginccring  Institute  (Sill)  in  support  of  SLI  s^Rcal-Timc  Sched¬ 
uling  in  Ada  Project  and  in  the  near  future  IBM  will  provide  another  set  of  hardware  to  the  ARTS  project  at  CMU  in 
support  of  joint  NOSC,  ONR,  and  IBM  funded  hard  real-time  distributed  system  research.  Phis  is  an  integrated 
systems  approach  to  the  problem  including  scheduling  algorithm  development,  OS  kernel  development,  and 
schcdulability  analysis  and  response  time  performance  monitoring  capabilities. 

For  a  number  of  years,  researchers  in  the  academic  community  have  asked  for  requirements  related  to  Department  of 
Defense  (DoD)  real-time  system  applications  (especially,  those  researchers  supporting  the  Office  of  Naval  Research  s 
Real-Time  System  Initiative).  These  requirements  have  generally  been  unavailable  to  academic  researchers  because  of 
the  classified  nature  of  the  projects  concerned.  Without  some  meaningful  characterization  of  these  types  of  systems 
academic  researchers  cannot  lie  sure  they  arc  addressing  problems  relevant  to  the  Dol)/Navy  community  and  the 
DoD/Navy  community  cannot  benefit  as  it  might  from  their  efforts  in  the  critiial  area  of  distributed  hard  deadline 
real-time  systems.  This  paper  attempts  to  address  this  problem,  it  provides  distilled  functional  requirements  for  three 
synthetic  real-time  systems.  These  systems  arc  functionally  similar  to  those  that  might  he  found  on  future  U.S. 
Navy  surface  ships  and  submarines.  They  include  an  acoustic  sensor  system  scenario  driven  by  highly  periodic  proc¬ 
essing,  a  combat  information  center  scenario  driven  by  man  machine  interface  processing,  and  a  radar  system  scenario 
driven  by  threat  loading. 

The  scenario  specifications  are  intended  to  lie  used  for  real  time  distributed  systems  architecture  research.  Software 
systems  designed  to  meet  the  specifications  given  by  these  scenarios  will  exhibit  the  complexity  and  timing  constraints 
that  can  he  expected  to  be  found  in  a  variety  of  future  Navy  platforms.  I  lie  scenarios  arc  intended  to  be  used  as 
workload  benchmarks  for  comparing  algorithms  for  managing  shared  system  resources  in  a  dish  United  real-time  envi¬ 
ronment.  The  specific  systems  described  however  arc  contrived.  Their  functional  descriptions  have  been  taken 
from  open  literature.  This  data  represents  no  specific  system  either  deployed,  under  development,  or  proposed, 
however,  they  arc  based  on  many  years  of  experience  in  working  with  such  systems  and  they  arc  tailored  to  match  the 
laboratory  resources  that  might  lie  available  to  university  researchers.  Because  different  researchers  will  lie  working 
with  equipments  having  greatly  varying  capacities,  the  processor  and  communication  loadings  arc  sealable  via  key, 
scenario  dependent,  parameters  such  ns  the  number  of  beams,  the  number  of  operators,  the  number  of  inrgcls,  the  rale 
at  which  operators  page  displays,  the  rate  at  which  new  threats  appear,  etc. 

These  distributed  real  time  scenarios  assume  that  the  research  testbed  systems  contain  laigcl  application  processors 
interconnected  by  a  Local  Area  Network  (LAN).  Since  each  scenario  has  been  parameterized  so  the  communication 
and  processing  resource  rcquiicmcnls  can  lie  sealed  up  u  down,  this  allows  icscarchcr.s  to  find  the  iilili/alion  levels 
where  response  time  failures  (for  individual  tasks  and  messages)  occur  using  llicir  proposed  scheduling  tcchiuquc(s). 
This  'breakdown'  utilization  is  a  lignic  of  merit  which  is  useful  loi  comparing  results  on  similar  or  divergent  testbeds, 
for  the  same  or  different  scheduling  algorithms,  anil  across  a  varieiv  of  rcscaicli  teams. 


Hi 


1  This  research  has  been  performed  for  the  Office  of  Kav.il  Rrsrarrii  IO\Rf  as  pari  nl  as  Disinhulrd  Ural  lime  Ssstems  research 
contract  wuh  ||),\t  under  Office  of  Naval  Research  Contract  N'linOM  C  tlMS 


The  organization  of  the  paper  is  as  follows.  Sections  2.  3,  and  4  each  describes  one  of  the  three  scenarios.  There  are 
two  subsections  for  each  sccnaiio.  The  first  subsection  describes  the  operating  environment.  the  mission,  human  oper 
ator,  and  interfaces,  and  etilerion  for  selecting  hardware.  The  second  subsection  gives  the  requirements  (processing, 
response  time,  and  data  flow)  by  function,  along  with  the  si/.c  and  rate  of  each  required  dataflow.  Section  5  describes 
an  implementation  of  the  first  scenario  wherein  the  functional  requirements  arc  mapped  onto  a  specific  system  architec¬ 
ture  and  schedulability  analysis  rcsnlLs  arc  discussed.  Using  the  example  providco  in  section  5  other  researchers  can 
arrive  at  their  own  architecture  for  this  as  well  as  the  other  two  scenarios. 

In  addition  to  this  paper,  a  spreadsheet  is  available  for  each  scenario.  The  spreadsheet  presides  the  means  for 
assigning  response  times  to  the  massages  and  tasks  running  on  the  testbeds  in  a  manner  that  meets  the  liming  require¬ 
ments  for  each  scenario.  Tor  the  first  scenario  this  information  is  contained  in  the  tables  presented  in  section  5. 


2.0  Submarine  Passive  Sonar 

This  section  describes  a  submarine  passive  sonar  system,  'flu  data  nroecssing  elements  involved  arc  typical  of  those 
found  in  detection  and  tracking  systems  on  submarinas,  surface  ships,  or  airplanes. 


2.1  A  Passive  Sonar  System 


Sonar  equipment  is  used  for  determining  the  presence,  location,  or  nature  or  objects  in  the  sea  from  underwater  sound 
the  objects  emit.  (10)  Active  sonar  transmits  an  acoustic  signal  which,  when  reflected  from  a  target,  provides  the  ">nar 
receiver  with  a  signal.  Based  on  .his  received  signal,  detections  and  position  estimates  arc  made.  Passive  sonar  bases 
its  detection  and  estimation  on  sounds  which  emanate  from  the  target  itself.  (3) 

In  passive  sonar,  and  the  receiving  subsystem  of  active  sonar,  the  received  acoustic  waveform  from  each  hydrophone 
consists  of  one  or  more  signals  and  background  noise.  The  hydrophone  converts  the  acoustic  wavcfoim  to  an  elec¬ 
tronic  signal.  The  signals  are  amplified,  filtered,  sampled,  and  digitized  in  a  signal  conditioner.  The  digitized 
hydrophone  outputs  from  the  signal  conditioner  arc  combined  by  a  digital  bcainformcr  to  form  a  set  of  'beams'.  A 
beam  increases  the  sound  from  the  beam  direction  and  reduces  the  sound  from  other  directions.  Beam  data  arc  then 
processed  to  obtain  detection  and  estimation  statistics.  Based  on  the  values  of  these  statistics,  the  system  decides  where 
targets  arc  located.  Detected  targets  are  tracked  by  modifying  the  bcamformcr  parameters  and  'steering'  a  beam 
toward  the  target. 

A  detected  target  is  also  analyzed.  Analysis  will  include  classification,  d.slinguishing  a  signal  returned  from  a  target 
with  regard  to  the  type  of  target  that  produced  the  signal.  A  target  is  chssificd  by  the  signal  frequency  spectrum  and 
dynamics  (e.g.,  a  school  of  fish  versus  a  submarine)  of  its  target  signal. 


Figure  1 .  Submarine  Sonar  Processing  Resources 


The  system  described  below  is  designed  to  delect  and  Irnck  submarine  targets  which  can  operate  at  any  speed  from  0 
to  15  knots  at  any  depth  from  0  to  500  feet.  The  target  sound  source  is  assumed  to  consist  of  vibrational  harmonics 
from  rotating  machinery  with  a  nominal  rotation  rate  of  2400  IIPM.  Therefore,  it  is  expected  that  die  returned  signal 
from  a  submarine  contains  a  fundamental  4011?.  component  and  the  lirst  three  harmonics. 


The  data  processing  load  for  a  sonar  system  is  roughly  proportional  to  the  number  of  hydrophones,  number  of  beams, 
and  the  sample  rate.  The  larger  the  array  of  hydrophones  the  greater  the  hcainforincr  gain  and  the  greater  the 
detection  range.  The  finer  the  beam  width,  the  finer  the  display  resolution  which  assists  in  resolving  multiple  targets 
even  though  they  appear  close  together.  Some  of  the  beams  arc  used  for  detection  displays,  some  for  tracking  targets, 
and  some  just  for  listening.  Typically  the  number  of  detection  beams  is  fixed,  so  the  detection  processing  load  ’.nics 
little  over  time.  The  number  of  steered  tracker  beams  may  change  as  targets  come  and  go.  When  the  number  of 
tracker  beams  is  changed,  the  tracking  load  changes  proportionally. 


Hgurc  1  shows  the  nominal  configuration  of  standard  computer  resources.  I  he  Signal  Conditioning  and  the 
Bcamforming  functions  arc  performed  in  non  standard,  custom  built  hardware.  This  custom  built  equipment  is 
channel  attached  to  a  standard  processor.  All  of  the  standard  processors  within  the  system  arc  nctwnr„cJ  together. 
External  equipment  is  attached  to  standard  processors  by  channels  at  points  determined  b,  the  way  the  functions  arc 
partitioned.  In  this  configuration,  the  analog  audio  output  is  .sumed  h.  he  ..oit.-np  directly  from  'lie  standard 
processors  attached  to  the  custom  hardware.  An  allcrn.uivc  design  viMi  h-ss  cabling  would  he  to  me  the  digital  data 
path  Tor  the  audio  data  and  perform  the  reconstruction  at  the  workstations,  ibis  wm.id  rcqtmc  a  high  degree  of  clod, 
synchronization  between  the  workstations  and  the  custom  equipment  in  order  to  meet  the  liming  requirements  of 
section  2.2.8.  In  this  configuration  the  liming  requirement  of  section  2.2.8  must  only  lie  met  within  a  single  processor, 
not  between  processors  connected  by  the  I.AN. 


This  configuration  is  cltoscn  to  fit  the  passive  sonar  system's  mission  and  (tiviioiuncni.  Si/c  and  power  arc  important 
criterion  for  selecting  the  processing  equipment  Equipment  spaces  arc  usually  cramped  and  it  is  didictilt  to  mn 
cabling,  ir there  is  a  problem  with  the  reactor,  the  svsiem  must  operate  on  the  limited  power  available  Irom  the  ships 
batteries.  Power  consumption  also  creates  heat,  beat  requires  cooling,  and  tooling  tan  make  .icoiohc  noise.  Equip¬ 
ment  weight  is  not  normally  a  significant  constraint. 


Another  criterion  is  that  the  system  should  use  as  few  unique  equipment  types  as  practical.  Ibis  reduces  the  life  cycle 
costs  by  reducing  the  number  of  dilfcrcnl  spare  parts  kept  on  h.iud  and  by  iiicicasuig  the  production  volume.  I  lie 
system  should  be  able  to  run  indefinitely,  that  is,  its  availabibn.  f’viih  a  defined  level  of  perlomi.nice)  should  be  near 
unity.  Some  performance  degradation  dining  m.iinlcii.'uic e  lime  is  pc  riniiic d.  hut  the  cnliie  usltm  should  never  he 
powered  off  or  reinitialized  dining  normal  operations. 


In  brief,  the  criterion  for  selecting  preferred  computer  equipment  tire: 

•  The  higher  the  processing  density,  the  belter. 

•  The  smaller,  the  belter. 

•  The  less  heal,  the  better. 

•  The  fewer  types,  the  belter. 

•  The  higher  the  availability,  the  belter. 


2.2  Data  Processing  for  Passive  Sonar 

The  time  critical  processing  functions  arc  shown  in  figure  2.  These  include: 

•  Signal  Conditioning 

•  Dcamforming 

•  Detection 

•  Tracking 

•  Analysis/CIassification 

•  Stabilization 

•  lime  Synchronization 

•  Audio 

The  processing  and  I/O  requirements  are  specified  buow.  When  this  scenario  is  used  for  tests,  the  load  on  the  com¬ 
puter  resource  may  be  varied  by  changing  the  performance  parameters.  These  arc: 

•  N  -  the  total  number  of  formed  beams. 

•  K  -  the  number  of  hydrophones 

•  /Vr  -  the  number  of  tracking  beams. 

•  A'fl  -  the  number  of  audio  beams. 

•  A'rf  -  the  number  of  detection  beams. 

•  Ac  -  the  number  of  analysis  beams. 


Figure  2.  Passive  Son:!.-  Interfaces 


in  a  real  s^lcm,  these  parameters  would  he  lixed  and  resources  would  he  added  until  timing  tcqtiii emetils  were  reli¬ 
ably  met. 

'Hie  response  time  requirements  arc  given  in  terms  of  when  data  enters  or  leaves  the  system.  A  liming  requirement 
stated  for  one  function  may  imply  timing  constraints  on  other  functions.  Thus  the  timing  requirement  for  the  Track 
function  limits  the  time  the  bcamforming  can  take,  f  igure  3  shows  the  relationship  between  the  functions  and  the 
system  response  time  requirements. 

2.2.1  Signal  Conditioning:  The  Signal  Conditioning  function  (SCI)  contains  amplifiers,  analog  filters,  automatic  gain 
control,  sample  and  hold  circuits,  and  A/0  converters. 

SC  amplifies,  filters,  and  converts  the  hydrophones'  signals  into  synchronous,  discrete  time  samples.  I  his  produces  the 
data  and  timing  that  drives  the  rest  of  the  system.  SC  is  performed  in  special  purpose  hardware  that  produces  samples 
at  512  Hz.  That  is,  the  voltage  amplitude  is  sampled  from  each  hydrophone  512  limes  a  second.  (3) 

See  Figure  3. 

2.2.2  Beamforminq:  The  Delay  and  Sum  Bcamforming  function  (HI")  delays  the  lime  samples  from  each 
hydrophone,  scales  and  sums  them.  This  increases  the  Signal  to  Noise  Ratio  (SNR)  for  signals  from  specific  directions. 

HF  will  stabilize  beams  by  changing  the  beam  delays  to  correct  for  sensor  position  and  reflect  the  new  direction  of 
tracker  beams.  HF  then  sums  the  weighted  samples  to  form  the  beams.  All  of  the  sensors  arc  used  to  compute  each 
beam.  HF  is  also  performed  in  special  purpose  hardware. 

Input 

•  Time  -  Current  time.  date,  and  sampling  pulse. 

•  Steer  -  Updated  delay  coefficients  for  aiming  the  tracker  beams. 

•  Position  -  Location  and  attitude  vectors  of  platform  and  sensors. 

Timing  Requirements  HF  computes  beams  fast  enough  to  keep  up  with  the  Signal  Conditioning,  flic  beam  samples 
arc  blocked  into  messages  frequently  enough  to  meet  the  timing  requirements  of  Detection,  [rack,  and  Audio  Recon¬ 
struction.  The  position  data  used  to  stabilize  beams  must  he  less  than  0.5  seconds  old.  See  I  igurc  3. 

Output 

•  DclcclBcnms  -  Acoustic  amplitude  time  samples  for  detection. 

•  TrackBcams  -  Acoustic  amplitude  lime  samples  for  tracking. 

•  AudioBcams  -  Acoustic  amplitude  time  samples  for  listening. 

•  ClassBcnins  -  Acoustic  amplitude  time  samples  for  analysis. 

2.2.3  Detection:  The  Detection  function  (DF.f)  formats  beams  to  allow  an  operator  to  find  new  signals. 


Input 

•  DctcctBcams  -  Acoustic  amplitude  lime  samples  for  detection. 

•  DctcctSclects  -  Threshold  selections  and  cursor  position. 

•  Position  -  Location  and  attitude  vectors  of  platform  and  sensors. 

Processing  DLT  compares  the  amplitude  of  the  beams  to  scheted  iht.sholds.  changing  the  data  units  to  levels  nr 
quanta.  T  his  requantized  data  is  integrated  over  time,  filtered,  and  fnrmallcd  Tor  dispia,.  Only  a  pm  non  of  the  infor¬ 
mation  is  displayed  for  every  beam.  Additional  information  about  pai titular  beams  i<  provided  to  ihc  display  when  the 
operator  makes  a  selection  with  the  display  cursor.  Pioccsving  will  require  10* AW  thousand  instruction  per  second 

(KIPS). 

Timing  Requirements  Detection  display  data  shall  be  sent  at  least  four  limes  a  tcvnnd.  I  lie  display  of  detection  data 
shall  be  synchronized  to  within  100  milliseconds  or  the  Audio  data.  See  I  igurc  3. 

Output 

•  Detect  Display  -  Time  hearing  plots  of  signal  strength. 

2.2.4  Track:  Hie  Track  function  FI  R)  steers  beams  to  follow  impels  of  interest. 


Input 


•  TrackBcams  -  Acoustic  amplitude  time  samples  for  tracking. 

•  Time  -  Current  lime,  date,  and  sampling  pulse. 

•  TrackSclecls  -  Tracker  assignments  and  display  options. 


Processing  TR  shall  use  the  track  beams  to  compute  estimated  hearing  and  hearing  rale  for  assigned  tracks.  TR  shall 
forward  the  results  of  these  computation  both  as  Track  records  and  as  plots.  i‘R  shall  update  the  direction  of  the 
Track  beams  to  follow  the  targets.  The  compulations  will  require  about  1 0 * A’/  KIPS. 

Timing  Requirements  Track  beam  directions  need  to  he  updated  to  keep  targets  from  being  lost,  timely  feedback  is 
essential.  Less  than  one  second  shall  elapse  from  sshen  a  beam  sample  is  taken,  and  the  informa.-on  from  that  sample 
is  used  to  form  subsequent  beams.  See  Figure  3. 

Output 

•  Tracks  -  Fslimalcd  bearing,  bearing  rate,  and  notations. 

•  TrackDisplay  -  Tracker  location  and  quality  formatted  for  display. 

•  Steer  -  Updated  delay  coefficients  for  aiming  the  tracker  beams. 


Figure  3.  Front  Fnd  Signal  Processing 


2.2.5  Analysis:  The  Analysis  function  (Cl  )  identities  larinis  ol  interest. 
Input 

•  ClnssBcams  •  Acoustic  amplitude  lime  samples  lor  analvsis 

•  Time  •  Current  time.  dale,  and  sampling  pulse. 

•  Position  -  Location  and  altitude  vectors  of  platform  ami  seosois. 

•  ClnssSelccIs  •  Display  options  and  eompaiisnn  (Itoiics. 


Processing  CL  shall  compare  information  from  selected  beams  against  known  targets.  Automatic  comparisons  shall 
occur  continually.  Automatic  comparisons  will  take  50*Ac  KIPS.  Specific  comparisons  occur  upon  operator  selection. 
Results  from  the  comparison  shall  appear  as  annotations  on  Detection  and  I  rack  displays.  A  single  comparison  will 
take  100  thousand  instructions  (KI). 


Timing  Requirements  Results  from  specific  comparisons  shall  he  presented  to  the  operator  within  I  second  of 
selection. 

Output 

•  ClassDisplay  -  Annotations  for  the  Detection  and  Track  displays. 

2.2.6  Stabilization:  The  Stabilization  function  (I’K)  broadcasts  die  current  location  of  the  platform  and  hydrophones. 
Input 

•  Fix  -  Navigational  position,  altitude,  heading,  and  speed. 

Processing  PK  shall  compute  attitude  vectors  for  the  platform  and  sensors.  The  resulting  position  data  shall  he  scut  to 
each  of  the  other  functions.  Each  computation  will  lake  10  KI. 

Timing  Requirements  Position  information  shall  reach  die  functions  within  200  milliseconds  'the  fix  being  taken. 

Output 

•  Position  -  Location  and  attitude  vectors  of  platform  and  sensors. 

2.2.7  Time  Synchronization:  The  'lime  Synchronization  function  fTS)  provides  the  current  time  throughout  the 

system.  t 

Processing  T5  will  superimpose  the  current  GMT  into  the  stream  «»f  liming  pulses,  and  pass  the  icsuhiug  lime  infor¬ 
mation  to  each  of  the  other  functions. 

Timing  Requirements  Tftc  delivered  lime  signal  shall  be  accurate  enough  to  satisfy  the  i'rack  ret  jircmcnls  and  steady 
enough  to  satisfy  the  Audio  requirements.  Hie  timing  pulse  will  reach  the  Signal  Conditioning  a.iu  llcainfnrming  func 
lions  at  512  +/- 0.005  Hz. 

Output 

•  Time  -  Current  time.  date,  and  sampling  pulse. 

2.2.8  Reconstructed  Audio:  The  Reconstructed  Audio  function  (AU)  provides  high  Oddity  Oltcrcd  audio  signals 
along  a  beam  of  interest. 

Input 

•  AudioBcams  •  Acoustic  amplitude  time  samples  for  listening. 

Processing  AU  shall  reconstruct  an  analog  signal  from  the  hc.un  data  and  present  the  signal  to  the  operators 
headphones. 

Timing  Requirements,  figure  3  shows  the  timing  requirements  for  the  AU  function.  Syntlu  i/cd  audio  shall  he  pre¬ 
sented  to  the  operator  within  IDO  milliseconds  <>f  the  corresponding  display  data.  .Since  high  fidclil'.  reconstruction  is 
essential,  the  reconstructed  signal  may  slip  no  more  than  0.1(1  seconds  in  live  hours. 

Output 

•  Sound  -  Aralog  signal  for  operator's  headphones. 


Tabic  I.  The  data  flows 


Signal 

Description 

Rate  (I I/) 

Si/c  (Bytes) 

Samples 

32  bit  samples  for  each  element  each  second. 

512 

3*tf 

lime 

Pulse  indicating  when  to  lake  each  sample.  Maximum 
driflof  +/-  inr--of». 

512 

1  hit 

DcfcclBcams 

Blocks  of  32  hit  beam  samples  for  detection.  512 
samples  per  beam  per  second. 

TDD 

TIM) 

TrackBcams 

Blocks  of  32  bit  samples  for  Tracking.  51 2  samples  per 
beam  per  second. 

Till) 

1 IM) 

GassReams 

Blocks  of  32  bit  beam  samples  for  Analysis.  512 
samples  per  beam  per  second. 

TBI) 

TIM) 

AudioBcams 

Blocks  of  beam  samples  for  Audio.  512  samples  per 
beam  per  second. 

TIM) 

1BD 

DclcciDisplay 

Watcrfalling  detection  data.  May  he  replicated. 

4 

2*;Vr / 

Steer 

Updated  weights  for  the  Track  beams. 

TBI) 

2*A*/Yf 

Tracks 

Current  status  of  the  targets  of  interest. 

>  ! 

64‘fYr 

TrackDisplay 

64  bytes  of  light  reading  per  Track  beam  per  second. 

May  be  replicated. 

ITU) 

TIM) 

Qass  Display 

4096  bytes  of  frequency  data  per  analysts  beam  per 
second.  May  he  replicated. 

>4 

TIM) 

Position 

Latitude,  longitude,  pointing  and  velocity  vectors  for 
the  platform. 

<  16 

32 

Time 

GMT  encoded  onto  die  sampling  clock. 

TIM) 

X 

Sound 

f  ligli  Fidelity  analog  waveform.  May  he  replicated. 

Analog 

.N’iA 

Signal 

Analog  waveform  from  each  hydrophone. 

Analog 

N»A 

Fix 

Input  from  gyroscope. 

16 

24 

GMT 

Greenwich  Mean  Time  from  external  clock. 

1 

24 

Gain 

Control  isiiings  for  starling  the  signal  conditioning. 

Aperiodic 

snnn 

DclcctScIccts 

Input  from  the  Detection  operator.  May  he  replicated. 

>  10 

a 

TrackScIccts 

Input  from  Track  operator.  May  he  replicated. 

"4 

24 

ClassScIccts 

Input  from  Analysis  operator.  May  he  rcpiicnted. 

'  1 

32 

AtidioSclecls 

Input  from  the  operator.  May  he  replicated. 

>  in 

a 

The  data  flows  within  the  system  arc  shown  in  I  able  !.  Redundant  flows  (for  fault  recovery).  and  system  management 
data  flows  arc  not  shown.  In  addition  so  this  real  lime  traffic,  the  sv'tcm  will  li..ec  to  support  occasional  file  transfers 
of  up  to  10  Megabytes  in  length. 

When  multiple  operators  arc  using  displays,  each  will  have  a  up.ir.iU  'ct  of  headphones,  input  devices,  and  video 
surfaces.  Data  flows  that  have  to  he  reproduced  separately  for  cash  active  oporalor  arc  marked  Mac  he  replicated  . 

As  long  as  the  response  lime  requirements  arc  met.  the  him  king  f.nlors  and  me  wage  liamlcr  rates  for  mane  data  flows 
arc  fairly  arbitrary,  for  these  flows,  the  slcstriplinn  shows  how  mmli  data  must  lie  moves)  and  the  v/e*  and  rates  are 
marked  "nil)’. 


3.0  Submarine  CIC 


#] 

I J 


This  section  describes  a  cvnh.il  information  renter.  I  he  svstrm  is  discrihrd  as  on  a  wihui.iruit-  hut  is  (spiral  of 
command  anil  control  or  surveillant  e  systems  mi  submarines,  surf.nc  ships.  ,ir  laud. 


3.1  Combat  Information  Center 


Tlic  information  center  provides  a  focus  for  all  collected  tactical  inhumation  and  platform  status.  I  he  center  Is  picnllv 
lias  up  to  20  workstations.  I.acli  workstation  can  access  and  display  any  or  all  of  the  system  data.  I  his  data  may 
include  everything  going  on  svilhin  hundreds  of  miles.  All  surface,  air.  and  sni»  surface  targets  mas  he  plotted  against 
true  geographical  coordinates  and  topography.  A  full  track  history  is  kept  for  melt  target.  All  displavs  arc  kept 
current.  (6) 

Hie  amount  of  data  collected,  its  format  (text,  audio,  or  video),  and  the  number  «f  active  operators  determine  the  data 
processing  load.  Note  that  an  operator  may  he  a  background  processor  applying  classification  or  correlation  alco- 
rithms  to  the  arriving  reports. 

All  the  workstations  in  the  CK,  operate  on  the  main  track  file.  Ihc  track  file  contains  the  current  information  on  the 
position  and  identity  of  all  ships,  aircraft,  and  submarines  of  interest  to  i  sen  ship.  Information  ssithin  the  track  file  is 
updated  many  times  a  second.  (5)  A  single  function  called  I  rack  Update  fields  Hie  individual  changes  and  distributes 
Ihc  current  tracks  to  the  workstations  every  two  seconds. 

Each  workstation  combines  the  current  track  information  with  data  from  the  system  database  for  display.  Tacit 
display  is  either  static.or_intcractivc._  On.a.slatic  display ..lltc  ucsv-rcporls  arc  shassn  on.a  fixed  background.  On  an 
interactive  display,  an  operator  is  actively  pulling  more  information  from  the  system  database  as  nesv  tracks  arrive. 
Many  display  formats  arc  possible,  liacli  format  requires  diircrcut  data  elements. 

Many  of  the  equipment  selection  criterion  arc  a  result  of  trying  to  make  Ihc  operators  as  productive  as  possible. 
Display  consoles  must  be  responsive  and  comfortnhlc.  It  should  he  easy  to  replace  any  of  the  system  data  with  an 
update.  It  should  he  easy  to  allow  a  foreign  system  to  'log  in'  and  either  read  or  deposit  new  information. 

Space  and  power  arc  important  criterion,  ‘flic  system  should  use  as  few  unique  equipment  part  types  as  possible.  ‘I  his 
reduces  the  life  cycle  costs  hy  reducing  the  number  of  different  spare  parts  kept  on  hand.  I  lie  system  should  be  able  to 
keep  running  for  long  periods  of  time.  Some  amount  of  scheduled  maintenance  lime  is  permitted. 

In  brief,  die  criterion  for  selecting  preferred  computer  equipment  arc: 

•  The  more  responsive  each  workstation,  the  heller. 

•  The  more  that  can  be  replaced,  die  belter. 

•  The  smaller,  the  better. 

•  The  cooler,  the  heller. 

•  The  fewer  part  types,  die  heller. 

•  The  longer  it  operates,  the  better. 

Figure  4  shows  the  configuration  of  standard  computer  resources  for  this  scenario.  'Ihc  operators'  display  workstations 
arc  attached  to  the  LAN.  The  other  systems  arc  channel  attached  to  Hie  standard  processors  at  pnints  determined  In¬ 
flow  the  functions  arc  partitioned. 


STANDARD  COMPUTER  RESOURCES 


The  lime  critical  processing  functions  include: 

•  Track  Update 

•  Overlay  Management 

•  Weapons  Monitoring 

•  Position  Keeping 

•  Time  Synchronization 

The  databases  arc: 

•  CIC  Information  Repository 

The  processing  and  I/O  requirements  arc  specified  in  the  following  terms: 

•  iVr  -  the  number  of  different  sensor  suites. 

•  iVc  -  the  numher  of  operators  steering  cursors.  \ losing  tire  iiusor  around  the  sateen  generates  .»  ipierv  for  test 
information.  The  results  appear  in  a  pop-up  window. 

•  A'/i  -  the  numher  of  operators  paging.  A  page  sclcetmn  cattails  an  image  from  the  .lal.rb.rtc.  !W  .-|tc»ator  c:.tm 
incs  the  image  and  (hated  on  what  is  found)  sdeets  another  page. 

•  Rp  -  the  rale  an  operator  flips  through  pages.  The  limes  an  operator  .hooter  m  turn  f„  nc.A  jiage  is  a  random 
variable. 

3.2.1  Track  Update:  the  I  rat k  Uptime  fnnttinn  fil")  manages  the  «olle,!iori  ami  ■littrilmlioii  of  if.ila  on  targets  of 
interest 

Input 

•  Tracks  -  Track  parameters  from  a  single  sensor 

•  lime  -  Current  time  ami  date 

•  Position  -  l  ocation,  velocity,  ami  attitude  vectors. 


d: 


Processing  7U  shall  collect  tracks  (rom  the  different  sensor  suites,  reconcile  tl'ilFcrent  sensors  tracking  the  same  target, 
and  apply  these  updates  to  the  track  file.  7  R  shall  distributed  the  updated  hack  file  on  a  regular  basis  I  lie  processing 
will  require  50 */V$  KIPS.  Updates  to  the  track  Ole  must  he  scrialbablc.  While  the  track  lilc  might  he  distributed 
across  several  standard  processors  and  updates  applied  to  different  parts  of  the  track  file  concurrently,  the  interleaved 
updates  must  produce  the  same  result  as  some  serial  application  of  those  updates.  (2) 

Timing  Requirements  Tracks  will  he  kept  current  enough  to  support  the  Ovcilay  Management  anti  Weapons  Moni¬ 
toring  functions. 

Output 

•  TrackPilc  -  All  current  target  tracks. 

•  TrackUpdalcs  -  Current  position  of  targets  of  interest. 

3.2.2  Overlay  Management:  The  Overlay  Management  function  (OV)  extracts  geographic  and  intelligence  data  from 
the  system  database  for  the  displays. 

Input 

•  PageSelect  -  Choice  of  new  image. 

•  InfoSclcct  -  Choice  of  new  readout. 

•  Position  -  Location,  velocity,  and  attitude  vectors. 

•  Text  Data  -  Information  for  a  readout. 

•  Image  Data  -  Information  for  a  page  display. 

Processing  OV  shall  retrieve  and  format  system  data.  Any  operator  can  view  any  system  data  (eg.  any  t.irgct  in  the 
track  Hie).  Preparing  an  read  out  will  require  10  to  100  Kf.  Preparing  a  new  page  will  require  20  to  40  KI. 

Timing  Requirements  Readouts  shall  be  returned  to  the  display  within  0.1  seconds.  Page  images  shall  he  returned  * 
within  0.5  seconds.  New  tracks  shall  be  less  than  3  seconds  old. 

Output 

•  Readout  •  Pop-up  text  for  the  track  picked  by  the  display  cursor. 

•  Image  -  Pixel  data  formatted  for  display. 

•  DataRcqucsts  -  Navigational  fix 

3.2.3  Weapons  Monitoring:  The  Weapons  Monitoring  function  (WM)  provides  the  data  and  liming  needed  by  the 
weapons. 

Input 

•  WpnSclect  -  Choice  of  weapon  configuration. 

•  WpnStatus  -  Current  state  of  each  weapon. 

•  Targets  •  Current  position  of  each  target. 

Processing  WM  shall  pass  configuration  and  aiming  commands  to  the  active  weapons  as  directed  by  the  operator's 
choices.  WM  shall  provide  current  track  data  on  operator  selected  targets  WM  shall  report  the  status  of  any  active 
weapons  to  both  the  operators'  workstations  and  the  system  database. 

Timing  Requirements  Updated  tracks  shall  reach  the  weapons  within  0  5  seconds  of  being  rcpoitcd  by  the  sensors. 
Status  shall  be  displayed  within  1 .0  second  of  being  reported  by  the  weapons. 

Output 

•  Wpn  Display  -  Display  of  weapon  status  and  tracks. 

•  WpnOrders  -  Steering,  Positioning,  and  configuration  commands. 

•  Wpn  History  -  Current  and  projected  stale  of  each  weapon. 

3.2.4  Position  Keeping:  I  lie  Position  Keeping  function  fl’K)  broadcasts  die  current  location  of  the  pl.ilfonn  and 
hydrophones. 

Input 

•  Pix  -  Navigational  lix 


Processing  PK  shall  compute  attitude  vectors  Tor  the  platform  and  weapons.  I  lie  icsulling  position  data  shall  he  sent 
to  the  database. 

Timing  Requirements  Position  information  shall  reach  the  weapons  within  200  milliseconds  of  the  fix  being  taken. 

Output 

•  Position  -  Location,  velocity,  and  attitude  vectors. 

3.2.5  Time  Synchronization:  The  Time  Synchronisation  function  (IS)  provides  the  current  time  throughout  the 
system. 

Processing  TS  shall  broadcast  the  current  lime  and  dale  to  each  of  the  other  functions. 

Timing  Requirements  Time  kept  by  any  two  computers  within  the  system  shall  difTcr  by  no  more  Ilian  10  milliseconds. 
Time  marks  are  received  from  the  clock  at  a  I  llz  rale,  if  the  standard  processors  arc  executing  a  lime  protocol  such 
as  NTP  (7)  the  time  need  only  be  broadcast  every  few  minutes  since  the  system  can  allow  several  hours  to  pass  for 
initial  synchronization  to  become  established. 


Output 

•  Time  -  Current  lime  and  date. 


Table  2.  The  Data  Plows 

Signal 

Description 

Rate  (lb.) 

Si/.c  (l)ytcs) 

InfoSclect 

Choice  of  new  readout  data. 

2*A’c 

50 

Data  Request 

Queries  from  Overlay  Management  for  data. 

2*A'c+  Rp*Np 

100 

Targets 

Current  target  position  and  characteristics. 

0,5 

IK 

WpnOrders 

Weapons  settings  and  steering  commands 

1 

32 

WpnDisplay 

Current  weapons  status. 

>  1 

M 

ImageData 

Image  retrieved  from  the  database. 

1 M 

TextData 

Textual  data  retrieved  from  the  database. 

2*A'c 

100 

Wpnllistory 

Running  commentary  on  weapon  status. 

0.1 

11C 

WpnStatus 

Current  weapon  state. 

1 

32 

WpnSelect 

Weapon  display  choices. 

Aperiodic 

50 

PageSclect 

Choice  of  new  image. 

Rp'Np 

50 

Fix 

Input  from  gyroscope. 

16 

24 

GMT 

Greenwich  Mean  Time  from  external  clock. 

1 

24 

Image 

Pixel  data  ready  for  display. 

Rp'fS'p 

IM 

Position 

Latitude,  longitude,  pointing  and  velocity  vectors  for 
the  platform. 

'  lb 

■ 

Readout 

Text  for  cursor  readout  display. 

2*A'c 

50 

Time 

Greenwich  Mean  Time. 

TOD 

8 

TrackPilc 

The  entire  current  track  file. 

0.5 

IM 

TrackUpdntcs 

Changes  in  the  tracks  from  each  sensor  suite. 

A't 

IK 

Tracks 

Updates  to  the  tracks  from  each  sensor  suite. 

hid. 

AVI  K 

The  data  Hows  within  the  system  arc  shown  in  I  able  2  Redundant  (lows  (lot  fault  recovery),  and  system  management 
data  flows  arc  not  shown.  In  addition  to  this  real  time  Ir.illiv,  the  system  sill  have  to  suppoit  oit.isinu.il  (tie  transfers 
of  up  to  100  Megabytes  in  length. 

As  long  as  the  response  lime  lequircmeuls  arc  mil.  the  blinking  l.ulois  and  mrssage  hansfci  rales  lot  many  data  Hows 
arc  fail ly  arbitraiy.  I'or  these  Hows,  the  disci iplimi  shows  Imw  mm  It  data  miisi  lie  mmrd  and  the  m/c  and  rales  arc 
marked  TIH)'. 


4.0  Surface  Ship  Radar 

'I  his  section  describes  a  phased  array  radar  system.  Che  system  is  described  ns  shipbonul.  The  syslem  is  typical 
of  missile  search,  spacecraft  tracking,  and  air  defense  systems,  both  ship  and  land  based. 

4.1  A  Phased  Array  Radar  System 

A  phased  array  radar  uses  a  fixed  antenna  to  project  narrow  beams  of  energy,  each  beam  in  a  brief  instant  at  a 
particular  point.  These  pencil  like  beams  (dwells)  search  paiticular  \olumcs  of  space  according  to  a  computer  con¬ 
trolled  search  plan.  Signal  processing  is  applied  to  the  return  Horn  a  single  dwell  to  delect  a  target  against  background 
clutter  and  jamming.  The  information  on  detected  targets  arc  passed  to  data  processing  where  tracks  arc  developed 
and  targets  identified.  (8) 

When  a  track  is  classified  as  a  threat  and  engaged,  the  radar  search  plan  is  modified  to  more  frequently  dwell  on  the 
target.  This  improves  the  quality  of  the  track  provided  to  the  fire  control  system,  the  more  targets  detected  and 
engaged,  the  more  effective  this  system.(6) 

In  addition  to  air  defense,  this  system  can  be  used  for  air  and  sea  traffic  control  and  surveillance.  ,  T or  all  of  these 
tasks,  the  number  of  objects  simultaneously  tracked  is  important.  T  he  number  of  current  tracks  and  the  number  of 
engaged  targets  largely  determine  the  level  of  data  processing  load. 

An  anti-air  combat  system  must  fight  under  a  wide  range  of  conditions.  A  threat  may  be  Jctccted  over  the  horizon  by 
an  off-board  sensor.  Threats  may  be  high  to  low  flying,  fast  or  slow.  The  system  may  have  to  coordinate  with  other 
defensive  mechanisms.  Different  tactics  and  rules  of  engagement  may  be  in  cficct. 

As  described  below,  the  combat  system  is  defending  a  ship  against  low  flying  macli  5  missiles  using  a  counter  missile 
with  a  minimum  effective  range  of  4000  meters  and  a  fly-out  time  of  4  seconds.  Tor  each  threat,  a  shoot, look/shoot 
doctrine  is  assumed.  The  system  has  15  to  27  seconds  from  detecting  a  missile  to  destroy  it. 


STANDARD  COMPUTER  RESOURCES 


Figure  6,  Surface  Ship  Radar  Processing  Resources 

figure  6  shows  the  configuration  of  standard  computer  irvmun  for  this  sccnaiio.  In  a  real  system  there  will  be 
additional  attachments  for  operator  displays,  but  as  described  there  arc  no  time  inlicul  display  processes  and  these 
connections  arc  omitted.  I  he  radar  equipment  is  assumed  in  lie  all. u  lied  to  standard  processors  through  shared 
memory.  This  is  done  to  meet  the  liming  requirements  of  section  '  2.T 


Many  of  li  e  equipment  selection  criterion  arc  due  to  the  system  being,  installed  on  a  surface  ship.  Since  the  radar 
array,  missile  magazine,  and  launcher  arc  bulky,  space  and  weight  are  not  constraints  on  the  computer  equipment. 
The  system  should  use  as  few  unique  equipment  part  types  ns  possible.  I  Ins  reduces  Ihc  ITc  cycle  costs  by  reducing  the 
number  of  different  spare  parts  kept  on  hand.  The  system  needs  to  be  able  to  survive,  combat  damage.  A  shell  or 
missile  hit  can  destroy  all  the  equipment  within  several  meters.  Ihc  system  should  be  able  to  keep  tunning  for  long 
periods  of  time.  Some  amount  of  scheduled  maintenance  lime  is  permitted. 

In  brief,  the  criterion  for  selecting  preferred  computer  equipment  arc: 

•  The  more  tracks,  the  better. 

•  The  fewer  part  types,  the  belter. 

•  The  more  that  can  be  damaged  without  loss  of  critical  functions,  Ihc  belter. 

•  The  longer  it  operates,  the  better. 


4.2  Data  Processing  for  Surface  Ship  Radar 


Figure  7.  Surface  Ship  t’nlar  Interfaces 


The  lime  critical  processing  functions  include: 

•  Detect  Track 

•  Track  Initiation 

•  Search  Control 

•  Track  and  Identification 

•  Engage  Target 

•  Position  Keeping 

•  Time  Synchronization 

•  Intercept 

The  processing  and  I/O  requirements  arc  specified  in  the  billowing  lei  ms- 


•  T  -  the  number  or  active  tracks. 

♦  H  -  the  rale  hostilcs  arc  found. 

These  two  terms  arc  related  random  variables. 

4.2.1  Detection:  The  Detection  function  (DPT)  thresholds  the  icturns. 


Input 

•  Returns  -  Amplitude  of  the  completed  radar  dwells. 

•  Time  •  Current  time  and  date. 

•  Position  -  Location,  velocity,  and  altitude  vectors. 

Processing  DF.T  accepts  and  stores  returns  from  each  dwell.  When  enough  successive  returns  have  been  accumulated 
from  each  range  gate,  filters  arc  formed  separating  clutter  signals  from  target  signals.  Processing  rccpiircs  1 00  KIPS. 

Timing  Requirements.  Hircsholdcd  dwells  are  blocked  into  messages  frequently  enough  to  satisfv  the  I  rack  Initiation 
timing  requirements. 

Output 

•  Scans  -  Dwell  return  in  the  projected  target  direction. 

•  Finds  »  Dwell  returns  above  a  selected  threshold. 

4,2.2  Track  Initiation:  The  Track  Initiation  function  (I'R)  applies  area  thresholding. 


Input 

•  Finds  -  Dwell  returns  above  a  selected  threshold. 

•  Time  -  Current  time  and  dale. 

Processing  TR  counts  the  number  of  reports  above  the  detection  threshold  in  a  limited  area.  I  urge  groups  of  point 
sources  (e.g.  bird  flocks  or  decoys)  arc  eliminated.  This  requires  100*//  KIPS 

Timing  Requirements  TR  eliminates  spurious  tracks  from  the  set  of  targets  within  JO  seconds  of  initial  detection.  For 
some  targets  the  analysis  will  produce  ambiguous  results.  Up  to  25  seconds  worth  of  data  may  be  needed  to  definitely 
eliminate  a  track.  Thus,  to  meet  this  requirement  the  TR  processing  must  be  completed  within  5  seconds.  In  addition. 
TR  is  producing  tracks  for  Track  Identification  as  shown  in  Figure  8. 


Output 

•  Tracks  -  Targets  to  eliminate  as  spurious. 


4.2.3  Search  Control:  The  Search  Control  function  (SC)  schedules  the  radar  dwells. 

Input 

•  Requests  -  Request  for  a  series  of  radar  dwells. 

•  Position  -  Location,  velocity,  and  attitude  vectors. 

•  Time  ■  Current  lime  and  date. 

Processing  SC  accepts  requests  for  radar  dwells.  The  requests  .ire  built  into  a  schedule  of  radar  dwells.  This  schedule 
is  passed  to  the  radar.  This  will  require  900  KIPS. 

Timing  Requirements  Aiming  instructions  arc  calculated  at  1500  llz. 

Output 

•  Aim  -  Schedule  of  upcoming  radar  dwells. 

4.2.4  Track  Identification:  The  Track  Identification  function  (ID)  estimates  the  motion  of  targets. 

Input 

•  Scans  -  Dwell  return  in  the  projected  target  direction. 

•  Tracks  ■  Targets  to  eliminate  as  spurious. 

•  Time  -  Current  lime  and  dale. 

Processing  ID  lakes  raw  estimates  of  target  position  and  computes  smooth  I)  present  position,  2)  present  velocity,  and 
3)  predicted  position  estimates.  This  requires  100*  T  KIPS. 


Timing  Requirements  Request  for  dwells  will  lie  produced  from  data  at  mnsi  0.2  seconds  old. 


Output 

•  Requests  -  Request  for  a  scries  of  radar  dwells. 

•  Targets  -  Current  track  of  hostile  targets. 

4.2.5  Engagement:  The  Engagement  function  (EG)  decides  which  targets  to  attack. 

Input 

•  Targets  -  Current  track  of  hostile  targets. 

•  Time  -  Current  time  and  date. 

Processing  EN  applies  the  current  tactical  doctrine.  I  lie  threat  posed  by  targets  is  evaluated.  If  automatic  engagement 
is  permitted,  EN  decides  when  to  fire.  This  requires  8 'T  KIPS. 

Timing  Requirements  EN  will  evaluate  a  new  target's  threat  within  0.5  seconds. 

Output 

•  FircOrders  -  Orders  for  launching  missiles. 

4.2.6  Position  Keeping:  The  Position  Keeping  function  (PK)  broadcasts  the  current  location  of  the  platform  and 
sensors. 

Input 

•  Fix  -  Navigational  fix 

Processing  PK  shall  compute  altitude  vectors  for  the  platform  and  weapons.  The  resulting  position  data  shall  be  sent 
to  the  database. 

Timing  Requirements  Position  information  shall  reach  the  weapons  within  200  milliseconds  of  the  fix  being  taken. 
Output 

•  Position  -  Location,  velocity,  and  attitude  vectors. 

4.2.7  Time  Synchronization:  The  Time  Synchronisation  function  (TS)  provides  the  current  lime  throughout  the 
system. 

Processing  TS  shall  broadcast  the  current  time  and  dale  to  each  of  the  other  functions.  This  will  require  50  KIPS. 
Timing  Requirements  Time  kept  by  any  two  computers  within  the  system  shall  differ  by  no  more  than  10  milliseconds. 
Output 

•  Time  •  Current  time  and  dale. 

4.2.8  Intercept:  The  Intercept  function  (IX)  steers  missiles  to  selected  targets. 

Input 

•  FircOrders  -  Orders  for  launching  missiles. 

•  WpnStatus  -  Current  state  of  each  weapon. 

•  Time  -  Current  time  and  dale. 

•  Position  -  Location,  velocity,  and  altitude  vectors. 

•  Results  •  Radar  returns  from  the  missiles. 

Processing  IX  configures  and  launches  missiles  as  diiccted  by  the  Engage  function.  In  (light  missiles  me  tracked.  I cr- 
minal  illumination  is  scheduled.  Effectiveness  is  assessed.  I  his  requires  40*//  KIPS. 

Timing  Requirements  Requests  for  dwells  to  (rack  in-flight  missiles  will  be  issued  at  4  I  lx. 

Output 

•  Steer  -  Steering,  positioning,  and  configuration  comma, ids. 

•  Requests  -  Request  for  a  series  of  radar  dwells. 


Table  3.  The  Data  Flows 

Signal 

Description 

Kate  (1 1/) 

Si/c  (Uytcs) 

Finds 

Freshly  detected  flying  objects. 

It) 

inn*// 

Scans 

Dwell  return  in  Ihc  projected  target  direction. 

It) 

ioo*r 

Tracks 

Intended  sequence  of  locations. 

1 

200*// 

Aim 

Schedule  of  upcoming  dwells. 

1 500 

400 

T  argots 

Current  hostile  target  tracks. 

"2 

100’  T 

FircOrders 

Orders  to  engage  specific  targets. 

Aperiodic 

64 

Position 

Latitude,  longitude,  pointing  and  ve!o<  v  -  for 

die  platform. 

<16 

32 

Time 

Greenwich  Mean  Time. 

-MI.S 

8 

Requests 

(from  1 19)  Dwells  to  identify  a  target. 

20 

50*  T 

Steer 

Missile  configuration  and  position  comma  l« 

10 

4000 

Requests 

(from  IX)  Terminal  Illumination  dwells. 

4 

400. 

Results  . 

Radar  returns  near  launched  missiles. 

20 

1000 

Fix 

Input  from  gyroscope. 

16 

24 

GMT 

Greenwich  Mean  Time  from  external  clock. 

1 

'24 

Returns 

Digitized  radar  returns. 

500 

2000 

WpnStatus 

Current  state  of  each  weapon 

20 

4000 

5.0  Submarine  Passive  Sonar  Scenario  Implementation 

The  submarine  passive  sonar  scenario  is  implemented  to  execute  under  the  ARTS  operating  system.  ARTS  provides 
'a  predictable,  analyzable,  and  reliable  distributed  real  lime  computing  environment.'  (9)  I  he  sonar  application  and 
ARTS  operating  system  run  on  SUN  3/I402  target  machines.  Network  communications  arc  provided  by  Illhcrnct  or 
the  Real-Time  Communications  Network  (RTCN).J 

The  sonar  application  transmits  messages  between  three  CPUs.  Messages  that  originate  from  or  (Tow  outside  of  the 
standard  computer  resources  illustrated  in  fi  ,..r:  I  arc  not  transmitted.  The  allocation  or  processing  to  CPU  is  speci¬ 
fied  by  the  spreadsheet  accompanying  the  sonar  scenario  description.  Additionally,  the  spreadsheet  defines  the  message 
rales,  task  rales  and  response  times  that  fulfill  the  scenario  requirements. 

A  computational  entity  under  ARTS  is  called  an  artobject.  (9)  An  artobjcct  is  implemented  for  each  message  sent  or 
received  within  the  standard  computer  resources.  The  artobjcct  creates  a  single,  periodic  task  (a  thread)  to  send  or 
receive  the  message  and  perform  associated  compulation.  Since  the  protocol  being  used  to  pass  messages  blocks  exe¬ 
cution  of  the  thread  receiving  or  sending  the  message,  the  one  thread  per  message  design  was  chosen  for  simplicity. 
Fach  recci' ing  task  is  implemented  by  an  ARTS  server  thread,  each  sending  task  by  an  ARTS  client  thread.  'The 
compulation  time  of  each  thread  is  simulated  by  running  a  C  Whetstone  (I)  benchmark  program  that  has  been  modi¬ 
fied  to  execute  one  thousand  non-floating  point  instructions,  lasks  that  do  not  send  or  receive  a  message  arc  imple¬ 
mented  by  combining  llicir  execution  time  with  another  process  in  the  CPU  running  at  the  same  rale.  Message  sizes 
and  task  computation  lime  arc  parameterized  to  vary  with  system  performance  parameters. 

Table  4,  Tabic  S  and  Table  6  describe  the  tasks  (threads)  running  in  e..*.i  CPU.  their  timing  requirements,  messages 
and  computation  time.  The  task  and  message  priorities  arc  indicated  as  well.  Priorities  aic  assigned  according  to  ihc 
rale  monotonic  (4)  scheduling  algorithm.  A  description  of  the  table  contents  follows: 

•  'Task'  contains  a  descriptive  name  of  the  task  function. 

•  'KI/cyclc'  is  the  number  of  kilo  instructions  executed  each  periodic  cwle  by  the  task.  If  message  si/c  varies 
according  to  performance  parameters,  the  foimula  is  imlR.ind.  I  lie  values  of  the  performance  parameters  used 
follow: 

-  Number  of  track  beams  (Nt)  =  5 


1  Sun  Microsystems.  Inc. 
5  HIM  Corp. 


—  Number  of  audio  beams  (Na)  =  6 

—  Number  of  detection  beams  (Nd)  =  50 

—  Number  of  analysis  beams  (Nc)  =  5 

—  Beamformcr  Rate  (BF)  =  4 

'Task  resp'  represents  the  amount  of  time  the  task  has  to  complete  its  processing  after  it  is  started  cacli  cycle.  The 
task  response  time  is  limited  to  the  task  period  in  this  implementation,  but  in  cases  where  the  response  lime  is 
actually  larger  than  the  period,  the  response  lime  is  listed  in  parenthesis. 

'Message'  provides  a  description  of  the  data. 

'Msg  resp'  provides  the  amount  of  time  the  message  may  take  to  be  transmitted. 

"Task  Rate’  is  the  periodic  cycle  time  of  the  task.  This  is  also  the  message  rate,  if  a  message  is  heine  passed. 

'S/R  (msg  pri)'  indicates  whether  the  task  is  Sending  or  Receiving  the  message.  The  message  priorities  are  listed 
in  parenthesis  for  each  send  message  for  RTCN  and  r.thcrnci.  Message  priority  is  determined  on  a  system  basis 
based  on  the  effective  message  rate.  The  effective  message  rate  is  the  higher  of  the  actual  message  rate  or  the 
message  response  rate.  The  fastest  effective  message  rale  is  assigned  the  highest  priority.  lies  arc  arbitrarily 
broken.  Message  priorities  for  RTCN  range  from  a  high  of  230  to  a  low  of  30.  I'.lhcrnct  message  priorities  range 
from  a  high  of  0  to  a  low  of  7. 

'Size'  is  the  message  size  in  bytes.  If  the  message  size  varies  according  to  performance  parameters,  the  formula  is 
indicated.  The  performance  parameters  arc  listed  above. 

'Priority'  is  the  task  priority.  This  value  is  computed  based  on  the  task  rale  and  task  response  lime  using  rate 
monotonic  priority  assignments.  The  task  set  is  executed  with  the  ARIS  scheduling  policy  set  to  fixed.  The  task 
priorities  for  each  CPU  arc  computed  independently.  The  highest  priority  is  assigneJ  to  the  task  with  the  highest 
effective  task  rale.  The  effective  task  rate  is  the  higher  of  the  task  rate  or  the  task  response  time,  l  ies  arc  arbi¬ 
trarily  broken.  Thread  priorities  range  from  a  high  off)  to  a  low  of  127. 


Table  4.  Tasks  in  CPU  1 

Talk 

KI  f 

Cjde 

Taik  mp 
(ms) 

Menace 

M«t  rrtp 
(mi) 

1  ask 

Rati*  fh/) 

S/R  (mic 
pH) 

Sl/r  (In 

I’hnnly 

Update  Steerm*  '*• 

M(4*Na) 

100  (  200) 

AudioScIrai 

100 

in 

R 

48  (JfN'H 

5 

Specific  Companion 

jet) 

200 

ClanSclecti 

too 

K 

82 

10 

Specific  Comp  2 

N'A 

250  (300) 

ClanDliplay 

:oo 

■ 

S  (182/4) 

<120 
(|024  • 

NO 

13 

Estimate  Track*' 

6.3  (5'Nt 

*  BP) 

250 

Tracks 

A 

4 

S  (Itttf) 

80 

(Ift'NI) 

12 

Recompute  Delay*' 

*  3  (S'Nt 

RF) 

250  (500) 

none 

4 

■* 

Torm  Sample  1  H 

N"A 

100 

ClaisBeams 

250 

.1 

S  (180/5) 

in  (2' NO 

i 

Torm  Sample  2  H 

N"A 

1O0 

TrackReams 

250 

4 

S  (178/5) 

in  (2'\*t) 

% 

formal  Duplay" 

125 

f!Q*Nd  / 

RF) 

250 

Detect  Duplay 

200 

4 

5  (184/4) 

;nn 

<2\\M) 

11 

Rebuild  Sound" 

j  cio/nn 

250  (300) 

none 

4 

- 

Adjust  CltXk  hU 

3 

125  (400) 

Time 

mo 

X 

R 

8 

9 

Receive  New  pit  Hti 

2 

5(1 

Position 

100 

R 

R 

32 

2 

Form  Sample  3 

ICO 

TnckSelcrtj  A 

DelcctSrlects 

IOO 

10 

R 

f*  . 

3 

•  *  Estimate  Tracks  and  Recompute  Delays  were  combined  into  one  task:  Rale  =  4  hz,  Kl  =  10‘Nl/HF. 

•  **  Format  Display  and  Rebuild  Sound  were  combined  into  one  task:  Rale  =  4  hz,  KI  =  (IO*Nd,l)l‘)  +  (10.IH"). 

•  ***  Update  Steering  and  Form  Sample  3  were  combined  into  one  task.  Rate  =  IT  hz.  Kl  =  24.  Message  Size  = 
(8*Na)  +  64,  Priority  =  3. 

•  if  Form  Sample  1  and  Torm  Sample  2  were  combined  irio  one  task:  Rate  =  4  hz.  Message  Size  = 
(2*Nc)+(2«Nt),  Priority  =  7. 

•  ////  Adjust  Clock  and  Receive  New  Tix  were  combined  into  one  task:  Rate  =  8  hz.  Kl  =  5.  Message  Size  -  40. 
Response  =  50  ms.  Priority  =  2. 


Table  5.  Tasks  in  CPU  2 

K !/ 

Cycle 

Task  resp 
(ms) 

Message 

Msg  rrsp 
1ms) 

Task 

Rale  Ih/I 

SI R  Imse 
prl) 

<i/r  ih) 

Pnonty 

Get  Cursor** 

12  (2'Na) 

100 

AudioSelects 

100 

10 

S{20(,i\) 

4*  rt'N't) 

4 

Update  Cursor** 

10 

100  (200) 

TrackSclect* 

100 

10 

S (230/0) 

4X 

3 

Update  Cursor** 

t6 

100(200) 

DctectSelects 

100 

10 

s 

1* 

■■ 

Comparison  Request 

5 

100 

ClassScIccts 

300 

Aper  1  6 ) 

5  (174-7) 

52 

* 

Display  Comparison 

5 

100 

ClassDIsplay 

200 

4 

R 

5120 

11024  • 

\Y> 

7 

Automatic  Comparison 

62.5 

(50*  Nc/ 

m 

250 

CUssReams 

250 

4 

R 

to  f\f21 

10 

r.ttimate  Tracks  ••• 

6. 3  (5'Nt 
/DF) 

250 

Tracklleams 

250 

4 

R 

50  (N’t *2) 

n 

Show  Det  Display* 

% 

100 

DeteetDisplay 

200 

4 

R 

I  no 

(N'd*2) 

it 

Show  Track  Display* 

5 

100 

none 

4 

Adjust  Clock 

3 

125  (400) 

Time 

100 

DH 

R 

s 

9 

Rrcfivt  New  Fix 

2 

50 

Position 

100 

BSm 

R 

*2 

2 

•  *  Show  Del  Display  and  Show  Track  Display  were  combined  into  one  task:  Rate  =  4  hz.  Kl  =  13. 

•  **  Update  Cursor  for  track  and  detection  and  Get  Cursor  were  combined  into  one  task.  Rale  =  10  hz.  KI  = 
(2*Na)  +  36,  Message  size  =  (8*Na)  +  f>4,  Priority  =  3. 

•  ***  Automatic  Comparison  and  F.stimate  Tracks  were  combined  into  one  task:  Rate  '=  4  hz..  KI  = 
(50*Nc/BF)+  (5*Nt/nP),  Message  size  =  (Nc*2)  +  (Nt*2),  Priority  =  10. 


Table  6.  Tasks  in 

EPU  3 

Tajk 

Kl/ 

Cycle 

Task  rttp 
(ms) 

Message 

M*t  1Y«p 
(ms) 

task 

Rale  Ih?) 

S/R  (mtf 
pH) 

SI  ft  (t» 

Priority 

Forward  Track* 

5 

100 

Track* 

N'A 

d 

R 

so 

(NVIA) 

10 

Build  Time  Mej*a*e* 

3 

125  (400) 

Time 

ICO 

R 

S  (|RA/ 3) 

ft 

12 

Adjust  Clock* 

3 

125  (400) 

none 

r 

Compute  Attitude** 

to 

50 

Fojition 

too 

ft 

S  (lftft/2) 

32 

6 

Receive  New  Fix** 

2 

SO 

none 

ft 

•  *  Build  Time  Message  and  Adjust  Clock  were  combined  into  one  task:  Rate  =  8  Ii7.  Kl  =  6. 

•  **  Compute  Altitude  and  Receive  New  Fix  were  combined  into  one  task:  Rate  =  8  list.  Kl  =  12. 

Scheduler  1-2-3,  a  tool  that  can  determine  the  schcdulabilitv  of  a  task  set  (9)  was  run  on  each  CPU  load.  The  results 
are  shown  in  Figure  9.  The  aperiodic  tasks  in  CPU  1  and  2  were  not  included  in  the  analysis,  since  a  sporadic  server 
is  not  available  in  our  pre-release  version  of  the  tool.  With  the  performance  parameters  specified,  CPU  I  defines  a 
77%  CPU  load.  CPU  2  defines  an  82%  load  and  CPU  3,  31%;  all  the  CPUs  arc  schcdulahlc  according  to  the  rate 
monotonic  closed  form  analysis  capability  of -Scheduler  1-2-3.  I  he  task  period  used  was  the  shorter  of  the  task  rate  or 
the  task  response  lime.  Execution  times  were  based  on  the  amount  of  lime  the  Kl  routine  required  to  run  on  the  SUN 
3/140.  Times  smaller  than  the  clock  granularity  were  assumed  to  he  I  millisecond  per  Kl  as  a  worse  ease,  though  tests 
showed  the-CPU  time  to  be  slightly  faster. 

Simulations  run  using  Scheduler  1-2-3  showed  approximately  the  same  results  as  tlx  loscd  form  analysis  when  using 
the  rate  monolonic  scheduling  policy.  Simulations  showed  that  CPU  I  and  CPU  2  were  not  schedulablc  if  the  riFO 
scheduling  policy  was  used.  Figure  9  shows  the  CPU  utilization  Tor  each  CPU  as  computed  hy  the  closed  form  anal¬ 
ysis  and  the  simulations.  The  number  of  missed  deadlines  is  indicated  for  the  FIFO  simulations. 


Figure  9.  Scheduler  1-2-3  Results  for  the  Passive  Simnr  Scenario 
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6.0  Summary 

Three  scenarios  have  been  described  and  an  architecture  for  one  has  been  defined  and  analy/cd.  I  nch  is  functionally 
similar  to  what  can  be  expected  in  future  Navy  systems,  Knelt  has  been  parameterized  so  that  the  required  processing 
resources  can  be  sealed  up  or  down.  The  spreadsheet  contains  nominal  values  chosen  to  produce  a  moderate  load  on  a 
testbed  of  three,  3  MIP  machines.  Our  analysis  for  scenario  1  was  based  on  having  three  I  \1!P  machines.  The 
parameters  were  adjusted  accordingly  so  that  the  utilizations  did  not  exceed  100%  and  the  task  set  was  schedulahlc. 

The  resources  required  to  support  the  Submarine  Passive  Sonar  scenario  depend  on  the  number  of  hydrophones  and 
the  number  and  type  of  formed  beams.  The  more  phones  and  beams,  the  more  resources  required.  The  resources 
required  to  carry  out  the  functions  of  the  Submarine  QC  scenario  depend  on  the  number  of  operators.  I  he  Surface 
Ship  Radar  scenario  resources  depend  on  the  number  of  tracks  held.  I  he  spreadsheets  referred  to  m  this  paper  may 
be  obtained  from  Dr.  Jane  Lui  at  the  L’niverily  of  Illinois,  Urbana.  As  experience  is  gained  in  using  these  scenarios  we 
anticipate  that  they  will  be  refined  and  other  interesting  examples  will  be  generated  by  the  research  community. 
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